Due to advances in computing technology, businesses today are able to operate more efficiently when compared to substantially similar businesses only a few years ago. For example, internal networking enables employees of a company to communicate instantaneously by email, quickly transfer data files to disparate employees, manipulate data files, share data relevant to a project to reduce duplications in work product, etc. Furthermore, advancements in technology have enabled factory applications to become partially or completely automated. For instance, operations that once required workers to put themselves proximate to heavy machinery and other various hazardous conditions can now be completed at a safe distance therefrom.
While various advancements have been made with respect to automating an industrial process, utilization and design of controllers have been largely unchanged. In more detail, industrial controllers have been designed to efficiently undertake real-time control. For instance, conventional industrial controllers receive data from sensors and, based upon the received data, control an actuator, drive, or the like. These controllers recognize a source and/or destination of the data by way of a symbol and/or an address associated with the source and/or destination. Further, industrial controllers can include communications ports and/or adaptors; and sensors, actuators, drives, and the like, are communicatively coupled to such ports/adaptors. Thus, a controller can recognize device identity when data is received and further deliver control data to an appropriate device.
As can be noted from the above, data associated with conventional industrial controllers can be created, delivered, and/or stored with a flat physical address space. In other words, all that can be discerned by reviewing data received and/or output by a controller is the memory location where the data for an actuator or sensor and a status resides. Further, a descriptive name or tag can be associated with data in the memory of the controller, where the tag can be referenced as opposed to a flat physical address.
Conventionally, tags can be fixed at design time and changed with a runtime edit. Further, typically, where symbolic addressing (e.g., tag references) is used, a controller cannot execute an instruction to access data within the controller dynamically at runtime. It may be desirable to access (e.g., read/write) data within the controller itself dynamically at runtime, while the controller executes.
Further, memory in a controller may be segmented into isolated areas known as scopes whereby access to tag data in each scope is limited to the application program instructions embedded within code contained in the same scope. Traditionally, data that must be accessed by code within multiple areas or scopes must be placed into a global area that is commonly accessible. This can create complications if tag names are reused across the global and controller areas. It is desirable for application code contained in one program scope to be able to access data in another program scope without having to revert to a controller scoped tag implementation.